Hey everyone - My name is Daniel Veza and my talk today is about Creating the optimal editorial experience with Layout Builder. Very wordy title, I'm glad I got through it ok

Daniel Veza

PreviousNext

Using Drupal since 2014

  • https://www.drupal.org/u/danielveza
  • https://github.com/DanielVeza
  • DanielVeza in DrupalSlack

Like I said, my name is Daniel Veza, I work at PreviousNext as a developer and I've been using Drupal since 2014.

--

These slides for this talk are going to be on my Github later and are available at this URL, so if you want to go back later and have a look please do!

--

My username on Drupals Slack is DanielVeza, very original I know. I mainly hang out in the Australia-nz channel. I know I normally think of a bunch of questions as soon as I leave the room of a talk, so come chat with me there if you think of anything

Lets start with a pre layout builder history lesson about my least favourite form in Drupal, the manage display form. I won't go too far into this form since I'm sure we are all pretty familiar with it, but I couldn't even begin to count the number of times I made sweeping changes to this form and forgot to press save at the end. This works and does still work for creating content that all has a similar look and feel, with limited ability for the content editor to make content more dynamic or see their changes in real time out of the box. Sometimes having your content have the same look and feel is a requirement, so later in the talk I'm going to run through how we can still achieve this with Layout Builder.
A new requirement has come in, and our editors want the ability to create very dynamic, cool Landing pages. We don't have Layout Builder, so we reach for good ol paragraphs. I'm sure many of us will be familiar with building a dynamic layout in paragraphs but stepping into the poor content editors boots here, this is a really tough way to build a page. What is the page going to look like? I can guess what a the first three might look like, but what is a wedge image, and what on earth even is a Horizontal left aligned 5 sided cube. I don't even think a cube can be 5 sided. It's my first day here, I don't know what any of this means
This leads to revisions screens that descend, or in this case ascend into madness, like this. Our editor has had to make multiple changes to the page, saving it each time to see how the page looks. Ok, I know this is a silly example, I hope nobody is actually calling components names like that, because Layout builder isn't going to help here either, it can only do so much.
That leads us into the future, and how we can use Layout Builder to enhance our editorial experience.

Layout Builder

So, to start us off I've set up a demo site with Umami which uses Layout builder extensively. The benefits become clear right away, when you're editing a page, you can preview how the site is going to look while it's being edited. You can drag and drop blocks, you can add new content, all within the page itself. No more guessing how something is going to look, you just know. So thats amazing right? Things are already so much better for our editors. We don't have time to go through a full intro to Layout Builder, but there is a ton of information out there around Layout Builder, and installing and playing around with the Umami profile in Core is a good starting point.
This was my thoughts before I started at PreviousNext. I had really only played around with Layout Builder, but never used it on a proper site and to be honest, I was a little intimidated by it. We've spent a bunch of time building these consistent displays for our content, and handing over control to the editors to build their own pages was a bit of a scary idea. But it really doesn't have to be this way. At the end of the day, both us and the editors want to be able to create the best pages that really show off the site.

But Layout Builder is scary!

With that in mind, Lets enhance our editors experience with Layout Builder. There are 4 common modules we use across our sites that really help make this better.

Layout Builder modules

Layout Builder Claro
The first module is Layout Builder Claro. This is a simple theming only module that requires no configuration. As a reminder, this is what Layout Builder looks like out of the box -- After enabling Layout Builder Claro, its just been tidied up a touch to look at bit cleaner. All the links like adding a block or section stick out a bit more -- The other benefit of the Layout Builder Claro module is the improvements to the off canvas layout. Looking at the original LB, the off canvas is very small, really sticks out with WYSIWYG field. -- And looking at the off canvas with Layout Builder Claro, it's been given a lot more breathing room. -- And if you wanted to go even more extreme, we're proposing to add an "Advanced mode" to Layout Builder Claro which just takes this another step further. For the sake of this talk, I've made everything visible, but normally the add Block, and section links only show up on hover or focus. It also displays the name of the region and section that is being edited so rather than just seeing that you're editing Section 1, you're seeing that you're editing a content region in a default section, it's just all about giving more clarity to the editor. We've trailed this on one site so far, and the editors love it.
So our Layout builder now looks cleaner, lets help our editors out some more with the editorial process itself. The first module that helps us with this is Layout Builder Lock. Lets revist our Layout Builder screen for a moment. On this page here at the bottom we have a two column layout with an image on the left and four boxes on the right that have details like the cooking time etc. In this case these are pretty static layouts, we don't want editors adding new blocks here and breaking the layout. Out of the box they could do something like adding an image or the body field to one of the boxes in the right hand column, which probably isn't going to look great. -- Layout Builder Lock solves these problems for us. When editing a section you can start checking some of these boxes to restrict what can be done here. The best example of where something like this would be useful would be in a hero section. A hero section is most likely going to have an image, the title and maybe some subtext. For the most part they're going to be themed quite specifically and only work with certain blocks. So for a Hero section, in most cases we would want most of these ticked. We don't want the default blocks to be changed or new blocks added, so we would tick these first four boxes.
Layout Builder Lock
Layout Builder Restrictions
Out of the box with Layout builder, we don't have the control that we want. Editors can play fast and loose with the layouts, and there is an information overload for the editors when they try to add a new block. Out of the box, every single field and block is avialable in Layout Builder. So when editing a recipe, this means there is 76 blocks that can be used out of the box. This includes blocks like "powered by drupal", or under the content fields header there is fields like the revision log. This is where our next module, Layout Builder Restrictions comes to our rescue. It allows us to choose which of these blocks we want to be available to the editor. -- With Layout Builder restictions you can edit which blocks are available to the editor at the section or region level. -- In this instance, I've chosen to remove all blocks under the system category. It's pretty likely none of them will be needed. -- The next two checkboxes are used to allow or restrict cetain blocks in a category. In this example we've started to remove a large chunk of the content type fields. We can pretty safely remove a large chunk of them. How often is the editor going to want to embed the content under default revision or the revision log itself? I'm going to guess that number is zero. -- Now that we are editing the content again, we can see the block config form is much smaller. There was 76 now there is 20. Much better for the editor.
Layout Builder Browser
The last module I wanted to cover was Layout Builder Browser. Heading back into our Layout Builder screen here, some of these headings aren't that helpful. "core" "Content fields", "System" make sense to us, but aren't super clear for our editors. -- Layout Builder Browser allows you to sort our blocks into better categories for our editors. -- So now I've created a bunch of browser blocks under the recipe heading and configured my restrictions. Now we have the recipe heading with the nicer icons under this recipe heading.

Adding fields with Layout Builder

So, we've gone over our 4 modules and we've had some quick wins for making content easier to edit. But we do still have a problem when it comes to our editors adding fields with layout builder.
Our content editor is now wanting to add the authored by field to the layout. Makes sense, we've restricted the blocks and where they can be added, and this field is allowed here. So, putting on our content editor hat for a second, can anyone see why this might be difficult for our editor? -- This assumes that our poor editor knows what a Field formatter is and when they should use them. When we don't use Layout Builder, this formatter option is hidden from them and set on the Manage Display for the field. This problem will be ever more obvious if we end up adding extra custom formatters. Our editors shouldn't need to know how and when to choose a particular formatter, to them it doesn't even matter what a formatter is. This shows the form when adding the "Authored by" block. -- This is even worse when you look at the authored on field! There is so many options here. In most cases, All this configuration like the formatter, the date format and the timezone really should be hidden from the editor and default values used. So how do we solve this problem? I've tried to keep this talk light on code and focusing on quick wins with modules, but I think this is too important to leave out. 

abstract class FieldBlockBase extends BlockBase {

  abstract protected function getFieldItemList();

  abstract protected function getFormatterSettings();

  public function build(): array {
    return $this->getFieldItemList()?->view(
      $this->getFormatterSettings() + ['label' => 'hidden']
    ) ?: [
      '#cache' => [
        'tags' => [
          'node_list',
        ],
      ],
    ];
  }
}
What we have done on a recent large project is created a block plugin for all the fields we want the editor to be able to use. We start with an abstract class that all our new Block plugins will extend. In getFieldItemList you get the field values that you want to display. getFormatterSettings is the secret sauce in the whole setup. This is where you define the formatter settings, taking it out of the editors hands, like you would on the manage display form. And finally in the build function, you return a render array of the build field data, with the items and the formatter settings. 

final class AuthoredByBlock extends FieldBlockBase {

  protected function getFieldItemList(): ?FieldItemListInterface {
    $node = $this->getContextValue('node');
    return $node->get('uid');
  }

  protected function getFormatterSettings(): array {
    return [
      'type' => 'author',
    ];
  }
}
Here is an example of the authored by field that we were looking at earlier. You can see we are getting the UID from the node, and we are setting the formatter to author.
So now when the editor goes to add that block to the layout, we can see its a lot easier for them. All those settings that they don't need to know are gone and the form is easier to use and understand. Don't forget to add a Layout Builder Browser block and configure your restrictions! You can stop the original block from being added and make sure only the new one can be used.

So Layout builder is an awesome tool that empowers our editors to make dynamic content, with its visual layout being much easer to use over the generic node edit form. But it does need some help. -- With Layout Builder Claro, we can make our Layout builder look nicer, and make it even easier to use with the off canvas clean up. -- We have our three modules that enable us provide a cleaner content editorial experience. These help to prevent layouts from being broken, and stop information overload for the editors when they're adding a block. -- And finally we have our custom block plugins, which takes information like field formatters out of the editors hands and allows them to just focus on the content.

Summary

  • Layout Builder Claro
  • Layout Builder Restictions
    Layout Builder Lock
    Layout Builder Browser
  • Custom block plugins for fields.

I feel like I've only scratched the surface with how far you can go with Layout Builder. Hopefully I've eased some nerves that people might have about using Layout Builder and hopefully haven't introduced any new ones. Thanks so much for listening, any questions while we have a few minutes to spare?

Questions